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Die folgenden Angaben sind den vom Anmelder eingereichten Unterlagen entnommen 

Prufungsantrag gem. § 44 PatG ist gestellt 

(3) Zustandskopierverfahren fur eine Software-Aktualisierung 

© Zum Bereitstellen einer Vorhergehensweise fur die 
Software-Aktualisierung mit skalierbarer Storung wird 
ein Zustandskopierverfahren fur ein Rechensystem mit 
zumindest zwei logischen Partitionen vorgeschlagen. Ein 
Zustand einer neuen Software in einer Standby-Partition 
(6, 16) wird dem Zustand einer alten Software in einer 
ausfuhrenden Partition bei Fortfuhrung der alten Softwa- < 
re angeglichen. Die Daten werden zwischen der ausfuh- 
renden Partition und der Standby-Partition in skalierbarer 
Weise iibertragen, und sobald derselbe Zustand fur die 
Standby-Partition (6, 16) und die ausfuhrende Partition 
(16, 6) erzielt ist, wird die Durchfuhrung zu der neuen 
Software umgeschaltet. Dies ermoglicht die Skalierung 
des Umfangs der Storung aufgrund der Softwareaktuali- 
sierung auf einen zulassigen Umfang. 
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Beschreibung 

Gebiet der Erfindung 

Die vorliegende Erfindung betrifft die Aktualisierung von 5 
Software und insbesondere eine Funktionsanderung in 
Computer basicrtcn Systcmcn mit haufigcr Aktualisierung 
aufgrund neu hinzugefiigter Funktionalitat und/oder einer 
Korrektur von Fehlern. 

10 

Hintergrund der Erfindung 

Die Entwicklung von Daten verarbeitungsanlagen und der 
Software-Technologie fiihrt zu einem zunehmenden Bedarf 
fiir Verfahren zum Aktualisieren installierter Software. 15 

Die iibliche Vorgehensweise besteht ini Stoppen der 
Durchfuhrung der installierten Software, dem Laden der 
neuen Software und dem anschlieBenden Starten der neuen 
Software. Bei dieser Vorgehensweise werden keine internen 
Daten zwischen der alten und der neuen Software ubertra- 20 
gen. Weiterhin gehen bei diesem Verfahren eingerichtete 
Dienste verloren, und der Dienst wird wahrend dem Laden 
und dem Starten der neuen Software vollstandig gestoppt. 
Momentan wird dieses Verfahren typischerweise fiir Work- 
stations und Personal-Computer eingesetzt. 25 

Eine weitere Vorgehensweise zum Aktualisieren von 
Software ist in EP-A-0 201 281 beschrieben. Jedoch ermog- 
licht diese Losung keine storungsfreie Datenaktualisie- 
rungsfunktion, da jede erforderliche Umsetzung von Daten- 
meldungen durch die neu installierte Software selbst wah- 30 
rend deren Anlauf durchgefiihrt wird. 

Ferner wird in US-A-5 155 837 vorgeschlagen, die Ein- 
gabe von Daten fiir neue Dienste zu der neuen Software in 
einem ersten Schritt umzuschalten. Ferner wird bei Ab- 
schluB eines aktivierten Dienstes in der alten Software die 35 
Ausgabe der Daten von dem Dienst von der alten Version zu 
der neuen Version umgeschaltet. Jedoch kann mit dieser Lo- 
sung lediglich Software gehandhabt werden, die Dienste mit 
einer sehr kurzen Dauer implementiert, da die Software 
nach der alten Version erst bearbeitet werden muB, bevor die 40 
neue Softwareversion voll betriebsbereit ist. 

Demnach existiert bei alien bekannten Vorgehensweisen 
eine bestimmte Stoning des Systembetriebs im Fall einer 
Softwareaktualisierung. Diese Stoning liegt zwischen einem 
vollstandigen Herunterfahren des Systems iiber Stunden 45 
oder moglicherweise Tage hinweg und einer kurzen Unter- 
brechung moglicherweise lediglich im Hinblick auf einige 
begrenzte Teile der gesamten Systemfunktionalitat wahrend 
einiger Sekunden. Gegebenenfalls wird uberhaupt keine 
Stoning wahrgenommen, obgleich dies bei real existieren- 50 
den Systemen, wie Telekommunikationsvemiittlungen, 
nicht der Fall ist. 

Zusammenfassung der Erfindung 

55 

Im Hinblick auf die obigen Ausfiihrungen besteht eine 
Aufgabe der Erfindung in der Schaffung einer Vorgehens- 
weise fiir die Aktualisierung von Software, die mit minima- 
lcr Stoning rcalisicrbar und auf nahczu keine Stoning ska- 
lierbar ist. 60 

GemaB der vorliegenden Erfindung wird diese Aufgabe 
gelost durch ein Software-Bearbeitungsgerat vom Typ mit 
Aktualisierungs-Funktionalitat, enthaltend eine Speicher- 
vorrichtung, unterteilt in eine ausfiihrende Speicherpartitio- 
nierungsvorrichtung zum Speichern einer ersten Gruppe von 65 
Softwaremodulen und zugeordneter Daten, und eine 
Standby-Speicherpartitioniervorrichtung zum Speichern ei- 
ner zweiten Gruppe von Softwaremodulen und zugeordneter 



Daten, eine Aktualisierungs-Steuervorrichtung zum Aktua- 
lisieren eines Zustands der neuen Software in der Standby- 
Speicherpartitioniervorrichtung gemaB dem Zustand der al- 
ten Software in der ausfiihrenden Speicherpartitioniervor- 
richtung wahrend der Fortfiihrung der Durchfuhrung der al- 
ten Software, und eine Ubertragungsvorrichtung fiir die ska- 
licrbarc Ubcrtragung von Daten von der ausfiihrenden Spci- 
cherpartitioniervorrichtung zu der Standby- Speicherparti- 
tioniervorrichtung . 

Demnach wird das aktualisierende System in zwei logi- 
sche Partitionen aufgeteilt. Diese Partitionen konnen, miis- 
sen jedoch nicht unter Einsatz eines Prozessorpaares imple- 
mentiert sein. Hierbei enthalt gemaB der Erfindung eine als 
ausfiihrende Partition bezeichnete Partition die alte Soft- 
ware, die eine normale Softwarebearbeitung durchfuhrt. 
Ferner wird die neue Software in die andere Partition gela- 
den, die als Standby- bzw. Bereitschaftspartition bezeichnet 
wird, ohne Stoning der Durchfuhrung der Betriebssoftware. 
Die Software in der Standby-Partition wird in denselben Zu- 
stand gebracht wie die Software in der ausfiihrenden Parti- 
tion, so daB die neue Software in der Standby-Partition die 
normale Programmdurchfuhrung ohne jegliche Stoning 
ubernehmen kann. Dies wird durch Kopieren von Daten von 
der Betriebspartition durchgefiihrt. Da die alte Software und 
die neue Software nicht identisch sind, kann der Fall eintre- 
ten, daB Daten in eine fiir die neue Software geeignete Dar- 
stellung umzusetzen sind. GemaB der vorliegenden Erfin- 
dung erfolgt diese Umsetzung parallel zu und ohne Stoning 
der Betriebssoftware, die fortlaufend in der Betriebsparti- 
tion durchgefiihrt wird. 

Weiterhin ist es in dem Fall, in dem die Ubertragung 
samtlicher Daten an der alten Software nicht mehr praktika- 
bel ist, gemaB der vorliegenden Erfindung moglich, Daten 
teilweise von der alten Software zu iibertragen. Dies ennog- 
licht die Skalierung des Umfangs der Stoning aufgrund der 
Softwareaktualisierung in dem System. 

GemaB einer bevorzugten Ausfiihrungsform der vorlie- 
genden Erfindung enthalt die Aktualisierungs-Steuervor- 
richtung ferner eine Umschaltvorrichtung und eine Zu- 
stands vergleichsvorrichtung zum Umschalten der Durch- 
fuhrung zu der neuen Software, sob aid derselbe Zustand fiir 
die Standby-Partition und die Betriebspartition durch die 
Zustandsvergleichsvorrichtung detektiert ist. 

Somit erfordert gemaB der vorliegenden Erfindung das 
Umschalten von der alten Software zu der neuen Software, 
dalS der gesamte Zustand, wie er sich in samtlichen Daten 
der alten Software widerspielt, zu der neuen Software ko- 
piert und gleichzeitig, falls erforderlich, umgesetzt wird. 
Demnach ist es gemaB der vorliegenden Erfindung moglich, 
den Betrieb mit der neuen Software ohne jegliche Stoning 
fortzusetzen. Femer konnen in dem Fall, in dem Daten bei 
Programmen der alten Software vorliegen, die zum Zeit- 
punkt des Umschaltens nicht bearbeitet werden, diese vor 
dem Start der neuen Software kopiert und, falls erforderlich, 
umgesetzt werden. 

GemaB einer bevorzugten Ausfiihrungsform der vorlie- 
genden Erfindung ist jeder Speicherpartition zumindest eine 
Ubernahmevorrichtung zum Durchfuhren von Vorgabeak- 
tioncn fur den Fall zugcordnct, daB Daten im Zusammcn- 
hang mit der alten Software lediglich teilweise iibertragen 
werden, so daB eine spezielle Ubernahmevorrichtung unmit- 
telbar nach dem Umschalten aktiviert wird. 

Hier wird die spezielle Ubernahmevonichtung unrnittel- 
bar nach dem Umschalten aktiviert, und sie fiihrt Vorgabe- 
aktionen aus, die keine vollstandige Eingabe von Daten er- 
fordern. Obgleich in diesem Fall eine Stoning in einem be- 
stimmten Umfang auftreten kann, und zwar in dem Umfang, 
wie Daten der alten Software fehlen, ennoglicht die vorlie- 
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gende Erfindung durch die Miteinbeziehung von Vorgabe- 
aktionen jedoch eine Skalierung, die durch den Umfang der 
zulassigen Storung bestimmt ist. 

GemaB einer weiteren zusatzlichen Ausfuhrungsform der 
vorliegenden Erfindung weist die Aktualisierungs-Steuer- 5 
vorrichtung eine Fortsetzung der alten Software in der Be- 
tricbspartition dann an, wcnn cine Fchlcr situation vor dem 
Umschalten auftritt. Ebenfalls fiihrt sie eine Riick-Umschal- 
tung so durch, daB die Partition rnit der alten Software er- 
neut die Betriebspartition wird, und zwar in dem Fall, in 10 
dem ein Fehler wahrend der Durchfiihrung der neuen Soft- 
ware nach dem Umschalten auftritt. 

Tritt ein Fehler vor dem Umschalten auf, so wird die Ak- 
tualisierung der Software abgeschlossen, und die normale 
Softwaredurchfuhrung wird mit der alten Software in der 15 
Betriebspartition fortgesetzt. Tritt anderenfalls ein Fehler 
wahrend der Durchfiihrung der neuen Software nach dem 
Umschalten auf, so wird ein Riick-Umschalten so durchge- 
fiihrt, daB die Partition mit der alten Software erneut die Be- 
triebspartition wird. Hierbei kann die Riick-Umschaltung 20 
Schritte zum Kopieren von Daten und, falls erforderlich, fin- 
em Umsetzen aufweisen, in derselben Weise wie die Um- 
schaltprozedur. Demnach kann die Ruck-Umschaltprozedur 
ebenfalls mit begrenzter oder ohne jede Storung durchge- 
fiihrt werden. Alternativ kann sie ohne jegliches Datenko- 25 
pieren und -umsetzen durch AnstoBen einer Riicksetzproze- 
dur bzw. Recovery-Prozedur ruckgefuhrt werden, was typi- 
scherweise zu einem gewissen Umfang von Storungen 
fuhrt. 

Ferner wird gemaB der vorliegenden Erfindung die oben 30 
genannte Aufgabe ebenfalls gelost durch ein Zustandsko- 
pierverfahren fur ein Rechensystem mit zumindest zwei Lo- 
gikpartitionen, enthaltend die Schritte Aktualisieren eines 
Zustands der neuen Software in einer Standby-Partitionier- 
vorrichtung an den Zustand der alten Software in einer aus- 35 
fuhrenden Partitioniervorrichtung bei Fortfiihrung der 
Durchfiihrung der alten Software, Umschalten zum Durch- 
fiihren der neuen Software, sobald derselbe Zustand fiir die 
Standby-Partitioniervorrichtung und die ausfiihrende Parti- 
tioniervorrichtung erzielt wird. 40 

Demnach ist es durch Einsatz des Verfahrens gemaB der 
vorliegenden Erfindung moglich, eine hochwirksame und 
storungsfreie Aktualisierung von Software selbst dann zu 
erzielen, wenn alte Software vorliegt, die Dienste mit langer 
Dauer handhabt. 45 

GemaB einer bevorzugten Ausfuhrungsform des erfin- 
dungsgemaBen Verfahrens enthalt der Aktualisierungs- 
schritt ferner einen Initialisierungsteilschritt, der parallel zu 
und ohne Storung der in der Betriebspartition ablaufenden 
alten Software durchgefiihrt wird. 50 

Somit folgen auf die Aktualisierung der neuen Software 
gegebenenfalls die Initialisierungsroutine. Obgleich dies 
teilweise friiher erfolgen kann, beispiels weise unrnittelbar 
nach dem Laden der neuen Software, ist ein Teil dieser In- 
itialisierung durch Daten der alten Software bestimmt und 55 
kann nicht vorab durchgefiihrt werden. Die Initialisierung 
der neuen Software erfolgt parallel mit minimaler Storung 
der lib lichen Betriebs software, die in der Betriebspartition 
wcitcr ausgefiihrt wird. Da sich der Zustand der Betriebspar- 
tition fortlaufend verandert, ist der storungsfreie Aktualisie- 60 
rungsprozeB gemaB der vorliegenden Erfindung ebenfalls 
fortlaufend parallel mit der Initialisierung durchzufuhren. 

GemaB einer anderen weiteren bevorzugten Ausfuh- 
rungsform des erfindung s gemaB en Verfahrens wird der Ak- 
tualisierungsschritt wiederholt als HintergrundprozeB bis 65 
zum Umschalten zu der neuen Software durchgefiihrt, zum 
Beriicksichtigen des sich verandernden Zustand in der Be- 
Iriebspartilion. Ist der vollstandige Zustand, wie es sich an- 
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hand samtlicher Daten der alten Software darstellt, zu der 
neuen Software kopiert und, falls erforderlich, umgesetzt, so 
ist es moglich, den Betrieb der neuen Software ohne irgend- 
eine Storung fortzusetzen. Erfolgt ein Datenaustausch zwi- 
schen Programmen der alten Software mit Daten, die zum 
Zeitpunkt des Umschaltens nicht bearbeitet werden, so miis- 
scn dicsc auch kopiert und, falls erforderlich, umgesetzt 
werden. 

GemaB einer weiteren bevorzugten Ausfuhrungsform des 
erfindungsgemaBen Verfahrens werden Daten im Zusam- 
menhang mit alter Software lediglich teilweise ubertragen, 
und ein spezieller Ubernahmeschritt wird unrnittelbar nach 
dem Umschalten durchgefiihrt, zum Durchfuhren von Vor- 
gabeaktionen, die keine vollstandige Eingabe von Daten er- 
fordern. In diesem Fall kann eine gewisse Storung auftreten. 
Der Umfang der Storung ist davon abhangig, wieviele Daten 
der alten Software nicht vorliegen. Vorteilhafterweise kann 
prinzipiell eine Skalierung in dem Umfang erfolgen, der als 
geeignet angesehen wird. 

Ferner wird gemaB der vorliegenden Erfindung ein Zu- 
stands kopierverfahren geschaffen, und zwar fur ein verteil- 
tes Rechensystem mit mindestens einem Hauptprozessor 
und zumindest einem Remote-Prozessor, das die Schritte 
Aktualisieren der neuen Software in einer ersten/Standby- 
Speicherpartition des Remote-Prozessors enthalt, sowie ein 
Aktualisieren des Zustands der neuen Software zum Erzie- 
len eines Abgleichs mit dem Zustand in dem Hauptprozes- 
sor bei Fortfiihrung der Durchfiihrung der Software in dem 
Hauptprozessor, und ein Umschalten der Durchfiihrung der 
Software von dem Remote-Prozessor zu der neuen Soft- 
ware, sobald ein Abgleich mit dem Zustand in dem Haupt- 
prozessor erzielt ist. 

Dieses modifizierte Verfahren gemaB der vorliegenden 
Erfindung ermoglicht das Erzielen einer Aktualisierung von 
Softwareniodulen, die sich von Teilen der Softwaremodule 
unterscheiden, die in einem speziellen Software-Bearbei- 
tungsgerat gespeichert sind. 

Es ermoglicht auch die Aktualisierung nicht nur von Soft- 
ware, sondern auch von Hardware. Insbesondere ist das 
Umschalten der Durchfiihrung von Software zu einem ande- 
ren Software-Bearbeitungsgerat wahrend der Hardware- Ak- 
tualisierung bei einem Software-Bearbeitungsgerat vorgese- 
hen. 

Zudem wird eine kombinierte Aktualisierung von Soft- 
ware und Hardware bei unterschiedlichen Software-Bear- 
beitungsgeraten dadurch geschaffen, daB zunachst die Hard- 
wareteile verandert werden, und anschlieBend die Software- 
teile angepaBt werden, und zwar durch Einsatz des erfin- 
dungsgemaBen Verfahrens. Hierbei miissen nicht alle Kom- 
ponenten gleichzeitig angepaBt werden, und demnach be- 
steht keine Anforderung dahingehend, das verteilte Rechen- 
system global neu zu starten. 

Kurzbeschreibung der Zeichnung 

Nachfolgend werden bevorzugte Ausfuhrungsformen der 
vorliegenden Erfindung unter Bezug auf die beiliegende 
Zeichnung beschrieben; es zeigen: 

Fig. 1 ein Blockschaltbild des Softwarc-Bcarbcitungsgc- 
rats gemaB der vorliegenden Erfindung; 

Fig. 2 ein Blockschaltbild der in Fig. 1 gezeigten Aktua- 
lisierungs-Steuereinheit; 

Fig. 3 ein Diagramm des Zustandskopierverfahrens ge- 
maB der vorliegenden Erfindung; 

Fig. 4 ein FluBdiagramm gemaB dem in Fig. 3 gezeigten 
Zustandskopierverf ahren ; 

Fig. 5 ein Zustandsdiagramm zum Darstellen des Status 
einer Partition des Software-Bearbeitungsgerats; 
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Fig. 6a einen parallelen synchronen Modus zum Durch- 
fiihren von Software in beiden Parti tionen gemaB dem in 
Fig. 3 gezeigten Schritt 1; 

Fig. 6b einen Status beider Partitionen gemaB dem in Fig. 
3 gezeigten Schritt 2; 

Fig. 6c einen Status beider Partitionen gemaB dem in Fig. 
3 gezeigten Schritt 3; 

Fig. 6d einen Status beider Partitionen gemaB dem in Fig. 
3 gezeigten Schritt 4; 

Fig. 6e einen Status beider Partitionen gemaB dem in Fig. 
3 gezeigten Schritt 5; 

Fig. 7 die erfindungsgemaBe Vorgehensweise zum Aktua- 
lisieren der Software in einem verteilten Rechensystem mit 
einem Remote-Prozessor mit Vorladefahigkeit; 

Fig. 8 die Aktualisierung von Software in einem verteil- 
ten Rechensystem mit einem Remoteprozessor ohne EinfLuB 
auf die Kompatibilitat der Schnittstelle zu diesem nach der 
Software- Aktualisierung ; 

Fig. 9 die Aktualisierung von Software in einem verteil- 
ten Rechensystem mit einem Remoteprozessor mit einem 
EinfluB auf die Kompatibilitat der Schnittstelle zu diesem 
nach der Software- Aktualisierung; 

Fig. 10 die erfindungsgemaBe Vorgehensweise der Aktua- 
lisierung von Hardware eines Hauptprozessors in einem ver- 
teilten Rechensystem; 

Fig. 11 die erfindungsgemaBe Vorgehensweise fur die 
Aktualisierung von Hardware und Software in einem Re- 
mote-Prozessor eines verteilten Rechensystems ohne Ein- 
fluB auf die Kompatibilitat der Schnitt stelle hierzu nach der 
Aktualisierung; und 

Fig. 12 die erfindungsgemaBe Vorgehensweise fur die 
Aktualisierung der Hardware und der Software in einem Re- 
mote-Prozessor eines verteilten Rechensystems mit EinfLuB 
auf die Kompatibilitat der Schnittstelle hierzu nach der Ak- 
tualisierung. 

Beschreibung der bevorzugten Ausfuhrungsformen 

Fig. 1 zeigt ein Blockschaltbild einer Ausfuhrungsform 
des Software-Bearbeitungsgerats gemaB der vorliegenden 
Erfindung. Das Software-Bearbeitungsgerat gemaB der vor- 
liegenden Erfindung enthalt zwei Partitionen A und B. Fur 
die Partition A ist eine erste Prozessoreinheit 4, eine erste 
Speicherpartition 6 und eine erste Ubernahmeeinheit 8 vor- 
gesehen. Die erste Speicherpartition ist in einen ersten Da- 
tenspeicherab schnitt 10 und einen ersten Software-Spei- 
cherabschnitt 12 unterteilt. 

Ferner wird dieselbe Struktur fur die Seite B gewahlt, die 
eine zweite Prozessoreinheit 14, eine zweite Speicherparti- 
tion 16 und eine zweite Ubernahmeeinheit 18 enthalt. Wie 
bei der Seite A, ist die zweite Speicherpartition 16 in einen 
zweiten Datenspeicherabschnitt 20 und einen zweiten Soft- 
ware-Speicherabschnitt 22 unterteilt. 

Wie in Fig. 1 gezeigt, ist zum Koordinieren der Aktuali- 
sierung der Software zwischen der Seite A und der Seite B 
oder umgekehrt zusatzlich eine Aktualisierungs-Steuerein- 
heit 24 vorgesehen, die beide Prozessoreinheiten 4 und 14 
steuert, sowie eine Ubertragungseinheit 26 zum Koppeln 
der ersten Speicherpartition 6 mit der zweiten Speicherparti- 
tion 16. 

Wie in Fig. 1 gezeigt, sind die erste und zweite Ubernah- 
meeinheit 8 und 18 jeweils der ersten und zweiten Spei- 
cherpartition 6 und 16 zugeordnet, und zwar zum Durchfuh- 
ren von Vorgabeaktionen in dem Fall, in dem Daten im Zu- 
sammenhang mit der alten Software lediglich teilweise 
iibertragen werden. Insbesondere betreffen derartige Vorga- 
beaktionen eine neue Software, die keine vollstandige Ein- 
gabe von Daten erfordert. Sie besteht beispielsweise aus der 



Initialisierung von Datenvariablen auf einem spezifischen 
Wert. 

Wie oben dargelegt, ermoglicht dies eine Ubertragung 
von Daten durch die Ubertragungseinheit 26 in skalierbarer 
5 Weise, da nicht ubertragene Daten jeweils durch die Uber- 
nahmeeinheit 8 und 18 initialisierbar sind. Weiterhin be- 
wirkt die Ubertragungseinheit 26 entweder ein unvcrandcr- 
tes Kopieren von Daten oder eine Umsetzung derselben in 
eine neue Darstellung fiir die neue Software unter Steuerung 
der Aktualisierungs-Steuereinheit 24. Hier kann die Umset- 
zung der Daten parallel zu und ohne Stoning des Abschnitts 
der alten Software in der Betriebspartition erfolgen. Weiter- 
hin wiederholen die Aktualisierungs-Steuereinheit 24 und 
die Ubertragungseinheit 26 die Dateniibertragung in dem 
Fall, die vorab bereits iibertragen wurden, und zwar bei 
gleichzeitiger Fortsetzung des Betriebs der alten Software in 
der Betriebspartition. 

Zudem weist die Aktualisierungs-Steuereinheit 26 eine 
Fortfiihrung der alten Software in der Betriebspartition in ei- 
nem Fall an, in dem eine Fehlersituation vor dem Umschal- 
ten auftritt. Eine andere Option besteht in einer Riick-Um- 
schaltung derart, daB die Partition mit der alten Software er- 
neut die Betriebspartition in einem Fall wird, in dem ein 
Fehler wahrend der Durchfiihrung der neuen Software nach 
dem Umschalten auftritt. 

Wie in Fig. 2 gezeigt, erzielt die Aktualisierungs-Steuer- 
einheit eine Aktualisierung, die sich in bidirektionaler Weise 
durchfiihren laBt, derart, daB entweder die Speicherpartition 
6 oder 16 als Betriebspartition wahrend der Aktualisierung 
der anderen Partition 16, 6 als Standby-Partition dient, bei 
der die neue Software geladen wird. Bei diesem Aktualisie- 
rungsprozeB werden Daten von der Betriebspartition zu der 
Standby-Partition iiber die Ubertragungseinheit 26 in ska- 
lierbarer Weise iibertragen. 

Zum Erzielen dieser Skalierbarkeit ist die in Fig. 1 ge- 
zeigte Aktualisierungs-Steuereinheit 24 wie in Fig. 2 aufge- 
baut. Die Aktualisierungs-Steuereinheit 24 enthalt eine Zu- 
standsvergleichseinheit 28, eine Ubertragungssteuereinheit 
30, eine Umschalteinheit 32, eine Speicherverwaltungsein- 
heit 34 und eine Softwareladeeinheit 36. Die Zustandsver- 
gleichseinheit 28 ermoglicht den Vergleich des Zu stands 
von Daten und von Software in den beiden Speicherpartitio- 
nen 6 und 16. Ferner ist die Ubertragungssteuereinheit 30 
zum Erzielen einer skalierbar flexiblen Ubertragung von 
Daten oder Software zwischen den beiden Speicherpartitio- 
nen 6 und 16 vorgesehen. Die Umschalteinheit 32 fiihrt das 
Umschalten der Durchfiihrung der Software zwischen der 
Seite A und der Seite B oder umgekehrt unmittelbar dann 
durch, wenn die Zustandsvergleichseinheit 28 denselben 
Zustand fur die Betriebspartition und die Standby-Partition 
detektiert. Die Speicherverwaltungseinheit 34 ist zum Allo- 
kieren, Deallokieren oder Kompaktieren von Speicher ent- 
weder bei der Speicherpartition 6 oder der Speicherpartition 
16 vorgesehen, und ebenfalls zum Festlegen von Referenz- 
information hierin. SchlieBlich ist die Softwareladeeinheit 
36 zum Laden neuer Software in den Softwarespeicherab- 
schnitt 12, 22 jeder Partition 6, 16 vorgesehen. 

Nach der Beschreibung der grundlegenden Struktur des 
Software-Bearbeitungsgerats gemaB der vorliegenden Erfin- 
dung unter Bezug auf die Fig. 1 und 2 folgt nun die Be- 
schreibung der Funktionalitat dieser Komponenten sowie 
ihre Wechselwirkung unter Bezug auf die Fig. 3 bis 7. Ob- 
gleich im folgenden die Beschreibung der Aktualisierung 
der Software fiir die Seite B beschrieben wird, sollte es nicht 
als die vorliegende Erfindung einschrankend angesehen 
werden, die ebenfalls in die umgekehrte Richtung zu der 
Seite A durchfuhrbar ist. 

Die Fig. 3 zeigt die grundlegenden Schritte zum Durch- 
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fiihren des Zustandskopierverfahrens gemaB der vorliegen- 
den Erfindung. Wie in Fig. 3 gezeigt, fiihren in einem Schritt 
1 beide Partitionen einen parallelen synchronen Modus mit 
der Durchfuhrung beispielsweise derselben Software durch. 

Ferner betrifft der in Fig. 3 gezeigte Schritt 2 das Laden 5 
neuer Software in der Standby-Partition bei gleichzei tiger 
Fortsctzung der Durchfuhrung der altcn Software in der Be- 
triebspartition. Ferner erfolgt im Schritt 3 das Kopieren von 
Daten von der Betriebspartition in die Standby-Partition. 
Wie im unteren Teil im Zusammenhang mit diesem S chritt 3 10 
gezeigt, kann hiermit auch ein Umsetzen kopierter Daten in 
der Standby-Partition in eine Darstellung verbunden sein, 
die fur die neue Software geeignet ist. Hierbei wird das Ko- 
pieren und Umsetzen von Daten parallel zu und ohne S to- 
rung der Durchfuhrung der alten Software in der Betriebsp- 15 
artition durchgefiihrt. Weiterhin kann gemaB der vorliegen- 
den Erfindung das Kopieren und Umsetzen von Daten durch 
speziell vorgesehene Software oder Hardware durchgefiihrt 
werden. 

Wie in Fig. 3 gezeigt, erfolgt im Schritt 4 eine Initialisie- 20 
rung, die ebenfalls parallel zu und ohne Storung der alten 
Software erfolgt, die in der Betriebspartition ablauft. Derln- 
itialisierungsschritt wird entweder unmittelbar nach dem 
Laden der neuen Software in der Standby-Partition im 
Schritt 2 durchgefiihrt oder sobald wie moglich in dem Fall, 25 
in dem er von Daten abhangt, die von der alten Software im 
Schritt 3 kopiert werden. 

Wie oben beschrieben, konnen Daten im Zusammenhang 
mit der alten Software lediglich teilweise ubertragen wer- 
den. Spezielle Initialisierungsschritte werden vor oder un- 30 
mittelbar nach dem Umschalten zum Durchfiihren von Vor- 
gabeinitialisierungsschritten durchgefiihrt, die keine voll- 
standige Eingabe der Daten der alten Software erfordern. 

Wie in Fig. 3 gezeigt, erfolgt unmittelbar nach Erzielen 
eines geeigneten Zu stands in der Standby- Partition im 35 
Schritt 5 ein Umschalten zum Durchfiihren der neuen Soft- 
ware. Es ist zu erkennen, daB das Umschalten im Hinblick 
auf einzelne Softwaremodule unmittelbar nach dem Erzie- 
len desselben Zustands fur zugeordnete Softwaremodule in 
beiden Partitionen durchgefiihrt werden kann. Liegen Daten 40 
im Zusammenhang mit der alten Software vor, die zum Zeit- 
punkt des Umschaltens lediglich einer teilweisen Ubertra- 
gung von Daten nicht ubertragen sind, so konnen diese Da- 
ten immer noch, falls erforderlich, vor dem Start der neuen 
Software ubertragen werden. 45 

Wie in Fig. 3 gezeigt, wird im Hinblick auf den Schritt 3 
und den Schritt 4 der KopierprozeB zwischen den beiden 
Speicherpartitionen auch wahrend dem Initialisierungs- 
schritt fur die Standby-Partition fortgesetzt. Der Grund hier- 
fiir besteht darin, daB die alte Software fortlaufend wahrend 50 
dem AktualisierungsprozeB fortgesetzt wird und bereits vor- 
her iibertragene Daten iiberschreiben kann. Somit wird der 
UbertragungsprozeB wiederholt als HintergrundprozeB so- 
lange fortgefiihrt, bis das Umschalten zu der neuen Software 
erfolgt, um den sie verandernden Zustand der Betriebsparti- 55 
tion zu beriicksichtigen. Dieser wiederholte Aktualisie- 
rungsprozeB kann parallel zu dem Initialisierungs schritt fiir 
die Standby-Partition durchgefiihrt werden. 

Fig. 4 zcigt ein FluBdiagramm gemaB dem untcr Bczug 
auf die Fig. 3 erorterten AktualisierungsprozeB. Insbeson- 60 
dere ist ersichtlich, daB nach einem Schritt 1 und 2 zum La- 
den neuer Software und zum Initialisieren des Speichers 
hierfiir ein HintergrundprozeB fortlaufend solange durchge- 
fiihrt wird, bis das Umschalten stattfindet. Hier ist zu erken- 
nen, daB der HintergrundprozeB auch durch Aufteilen in 65 
mehrere Hintergrundprozesse durchfiihrbar ist. Wird der- 
selbe Zustand fiir die alte und neue Software detektiert, so 
findet ein unmittelbares Umschalten, gefolgt von einer Ab- 



frage, statt, um zu bestimmen, ob zu iibertragende Daten 
noch vorliegen, was die wiederholte Durchfuhrung der alten 
Software im Rahmen einer Schleife erfordert. 

Im folgenden werden spezifische Beispiele fiir das Zu- 
stands kopierverfahren gemaB der vorliegenden Erfindung 
unter Bezug auf die Fig. 5 und 6 beschrieben. Die Fig. 5 
zcigt die Darstellung des Zustands einer Spcichcrpartition 
unter Einsatz eines Zustandsgraphens, und die Fig. 6a bis 6b 
zeigen die Modification eines derartigen Zustandsgraphens 
wahrend des Ablaufs des Zustandskopierverfahrens. 

Wie in Fig. 5 gezeigt, wird ein Zustand einer Speicherp- 
artition unter Einsatz eines Zu stands graphen mit Knoten 
und Kanten dargestellt. Hier reprasentiert ein Knoten typi- 
scherweise unterschiedliche Datenzustande, und Kanten re- 
prasentieren eine Ubertragung zwischen unterschiedlichen 
Datenzustanden durch Ausfiihrung von Softwareniodulen, 
die den Kanten zugeordnet sind. Ein Beispiel besteht darin, 
daB der oberste Knoten Eingabedaten betrifft, die durch ein 
Eingabedaten-Verarbeitungssoftwaremodul in fiir die wei- 
tere Verarbeitung geeignete Daten umzusetzen sind. Knoten 
mit eingefiigten Kanten stellen die Wechselwirkung von 
zwei Softwareniodulen dar, bei denen die Ausgangsdaten ei- 
nes Softwaremoduls Eingangsdaten des anderen Software- 
moduls darstellen und umgekehrt. 

Wie in Fig. 6 gezeigt, eignet sich diese Darstellung zum 
Erlautern der in Fig. 3 gezeigten unterschiedlichen Schritte. 
Insbesondere betrifft Fig. 6 a den parallelen synchronen Mo- 
dus zum Durchfiihren derselben Software in der Betriebsp- 
artition und der Standby-Partition vor dem Start des Aktua- 
lisierungsprozesses. Wie in Fig. 6b gezeigt, wird wahrend 
dem Laden der neuen Software im Schritt 2 die anhand der 
Kanten dargestellte Wechselwirkung unterschiedlicher Soft- 
waremodule unterbrochen, und das Laden der neuen Soft- 
ware beginnt. Wie in Fig. 6b gezeigt, konnen Daten in unter- 
schiedliche Kategorien aufgeteilt werden, wie bereits oben 
dargelegt. Hier bezeichnen die schwarzen Knoten Daten in 
der neuen Software, die identisch von der alten Software zu 
kopieren sind. Im Gegensatz hierzu bezeichnen weiBe Kno- 
ten Daten der neuen Software, die in keiner Weise von Da- 
ten der alten Software abhangen. Ein typisches Beispiel wa- 
ren Daten, die neu aufgrund der Modification von Daten- 
strukturen eingefiihrt werden. Eine andere Kategorie von 
Knoten, die schraffiert gezeigt ist, betrifft Daten, die zum 
Angleichen an die neue Software eine Umsetzung erfordern. 
Eine weitere DifTerenzierung, die grau dargestellt ist, betrifft 
Daten, die lediglich eine Teilkopie oder -umsetzung, ausge- 
hend von der alten Software, unter zusatzlichem Einsatz des 
Ubernahmemechanismus erfordern, und zwar zum Reduzie- 
ren des an die neue Partition zu iibertragenen Datenum- 
fangs. Insgesamt wird, wie in Fig. 6c gezeigt, lediglich fiir 
die Daten der letzten drei Kategorien ein Kopier- und/oder 
Umsetzvorgang zwischen der Betriebspartition und der 
Standby-Partition durchgefiihrt. 

Das Ergebnis des in Fig. 3 gezeigten Schritts 4 ist in Fig. 
6d gezeigt. Nach dem Initialisieren der neuen Software wer- 
den Wechselbeziehungen der unterschiedlichen Datenkom- 
ponenten erneut eingefiihrt. Wie bereits oben unter Bezug 
auf die Fig. 3 und 4 dargelegt, wird das Zustandskopierver- 
fahrcn gemaB der vorliegenden Erfindung in dem Fall itc- 
riert, in dem Daten durch die alte Software wahrend des Ak- 
tualisierungsprozesses iiberschrieben werden. Somit zeigt 
die Fig. 6d die Situation vor dem Umschalten, bei der das 
Kopieren/Umsetzen auch nach der Initialisierung in Schritt 
4 fortgefiihrt wird. Nach dem Umschalten im Schritt 5 exi- 
stieren diese Kanten zum Darstellen des Kopierens/Umset- 
zens von Daten nicht mehr langer, wie in Fig. 6e gezeigt. 
Nach dem Umschalten entspricht der Status erneut dem 
oben beschriebenen, parallelen synchronen Modus. 
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Somit ist bei dem Zustandskopierverfahren der von der 
alten Software zu der neuen Software kopierte Status und 
gegebenenfalls der Gesamtzustand sowohl in der alten als 
auch in der neuen Version definiert. Prinzipiell kann der Be- 
trieb mit jeder der Softwareversionen durchgefuhrt werden, 5 
da der Zustand fur beide Versionen vollstandig ist. Wichtig 
fiir das Zustandskopierverfahren ist die Tatsachc, daB keine 
gleichzeitige Durchfuhrung von Software in der Betriebsp- 
artition und der Standby-Partition erfolgt, mit Ausnahme 
der Aktualisierungsfunktion selbst. 10 

GemaB dem erfindungsgemaBen Zustandskopierverfah- 
ren ist es auch rnoglich, den AktualisierungsprozeB vor dem 
Umschalten im Fall des Auftretens einer Fehlersituation zu 
beenden und den Betrieb mit der alten Software fortzuset- 
zen. Zudem ist das Durchfiihren einer Riickschaltung im 15 
Fall des Auftretens eines Fehlers wahrend der Durchfuhrung 
der neuen Software nach dem Umschalten so rnoglich, daB 
die alte Software erneut die Betriebssoftware wird. Dieses 
Ruckurnschalten kann zu einer Datenubertragung mit einem 
Datenkopiervorgang und der Umsetzung vom oben genann- 20 
ten Typ fiihren. 

Wahrend vorangehend das Zustandskopierverfahren im 
Hinblick auf ein Software-Bearbeitungsgerat beschrieben 
wurde, erfolgt nun die Beschreibung der Anwendung des 
Zustandskopierverfahrens auf ein verteiltes Rechensystem 25 
unter Bezug auf die Fig. 7 bis 12. 

Wie in Fig. 7 gezeigt, enthalt das verteilte Rechensystem 
einen Hauptprozessor 38 und einen Remote-Prozessor 40. 
T)'pischerweise weist der Hauptprozessor 38 die in Fig. 1 
gezeigte Struktur auf und ist in Fig. 7 nur teilweise gezeigt. 30 
Ferner ist ein Remote-Prozessor 40 vorgesehen, der zumin- 
dest die Option zum Vorladen von Software in eine Spei- 
cherpartition 46 des Remote-Prozessors 40 bieten muB. Al- 
ternativ kann auch der Remote-Prozessor 40 die Struktur 
des erfindungsgemaBen Software-Bearbeitungsgerats auf- 35 
weisen, wie in Fig. 9 gezeigt. Der Hauptprozessor 38 und 
der Remote-Prozessor 40 sind iiber eine Verbindungsleitung 
42 verbunden. Jeder der Remote-Prozessor ist mit zumin- 
dest einer Aktualisierungsvorrichtung 44 zum Koordinieren 
der Aktualisierung in dem Remote-Prozessor unter Wech- 40 
selwirkung mit dem Hauptprozessor 38 versehen. 

Die Fig. 7 zeigt im ersten Fall die Anwendung des erfin- 
dungsgemaBen Zustandskopierverfahrens in einem verteil- 
ten Rechensystem. Hier wird lediglich die Software in dem 
Remote-Prozessor 40 so aktualisiert, daB die neue Software 45 
anfanglich bei einer Speicherpartition 46 des Remote-Pro- 
zessors 40 geladen wird. Damit das Zustandskopierverfah- 
ren eingesetzt werden kann, muB der Remote-Prozessor 40 
ein Vorladen so ermoglichen, daB das Bereitstellen von 
Diensten wahrend dem Laden der neuen Software rnoglich 50 
ist, und daB nach dem Laden Daten, ausgehend von dem 
Hauptprozessor, aktualisiert werden konnen. 1st dies der 
Fall, so kann Software in dem Remote-Prozessor 40 ohne ei- 
nem globalen Neustart des verteilten Rechensystems aktua- 
lisiert werden. Hierfiir wird, sob aid die neue Software in 55 
dem Remote-Prozessor 40 installiert ist, der Zustand der 
Speicherpartition 46 in dem Remote-Prozessor gemaB dem 
Zustand der Speicherpartition in dem Hauptprozessor 38 ak- 
tualisiert, bei glcichzcitigcm Fortsctzcn der Durchfuhrung 
der Software in dem Hauptprozessor 38. SchlieBlich wird 60 
die Durchfuhrung der Software in dem Remote-Prozessor 
40 zu der neuen Software unmittelbar dann umgeschaltet, 
wenn ein Abgleich zu dem Zustand des Hauptprozessors 38 
erzielt ist. 

Ferner kann bei dem Zustandskopierverfahren ein schnel- 65 
les Aktualisieren des Remote-Prozessors 40 erforderlich 
sein, in Abhangigkeit davon, welche Art und wieviel Soft- 
ware zu aktualisieren ist. Hierbei bestehen in einem Fall, in 
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dem lediglich unkritische und/oder ein begrenzter Umfang 
der Software aktualisiert wird, keine hohen Anforderungen 
an die Aktualisierungsgeschwindigkeit. Demnach kann 
selbst bei Aktualisierung mehrerer Remote-Prozessoren 
eine Aktualisierungszeit erzielt werden, die konsistent zu 
der Unterbrechungszeit fiir einen AktualisierungsprozeB ist. 

Die Fig. 8 zcigt einen wcitcrcn Fall, gemaB dem Software 
nicht nur in dem Remote-Prozessor 40, sondern auch in dem 
Hauptprozessor 38 aktualisiert wird, und bei dem der Aktua- 
lisierungsprozeB einen EinfluB auf die Kompatibilitat der 
Schnittstelle hat. Hier wird die Softwareaktualisierung in 
zwei Schritten durchgefuhrt, indem zunachst die Software 
in dem Remote-Prozessor 40, wie oben dargelegt, aktuali- 
siert wird und anschlieBend die Software in dem Hauptpro- 
zessor 38 unter Einsatz des oben beschriebenen Zustandsko- 
pierverfahrens aktualisiert wird. Werden nicht alle Remote- 
Prozessoren in dem verteilten Rechensystem zur gleichen 
Zeit aktualisiert, so besteht keine Anforderung fiir einen glo- 
balen Neustart des Systems. 

Die Fig. 9 betrifft denselben Fall, wie den in Fig. 8 ge- 
zeigten, mit dem Unterschied, daB nach der Aktualisierung 
der Software in dem Hauptprozessor 38 und dem Remote- 
Prozessor 40 die Schnittstelle hierzwischen inkompatibel 
wird. 

In diesem Fall sollte auch der Remote-Prozessor 40 die 
oben unter Bezug auf die Fig. 1 beschriebene Struktur auf- 
weisen, so daB eine gleichzeitige Aktualisierung von Soft- 
ware in dem Remote-Prozessor 40 und dem Hauptprozessor 
38 bei hierzwischen modifizierter Schnittstelle durch gleich- 
zeitiges Durchfiihren des erfindungsgemaBen Zustandsko- 
pierverfahrens jeweils in dem Hauptprozessor und dem Re- 
mote-Prozessor 40 erzielt wird. 

Hierbei sollte in einem Fall, in dem nicht kritische Teile 
des verteilten Rechensystems betroffen sind, das Zustands- 
kopierverfahren eingesetzt werden, indem der veranderte 
Teil des Systems ausgekoppelt wird, anschlieBend gleich- 
zeitig die Software aktualisiert wird, schlieBlich die veran- 
derten Teile des verteilten Rechensystems wieder eingekop- 
pelt werden. Sind Daten von der alten Software zu der neuen 
Software ubertragen, so sollte das Kopieren/Umsetzen vor 
dem Start und dem Einkoppeln der neuen Software durchge- 
fuhrt werden. Sind andererseits kritische Teile wahrend der 
Aktualisierung der Software betroffen, so sollte der Remote- 
Prozessor 40 vorab mit der neuen Software geladen werden, 
um eine zu lange Unterbrechungszeit des verteilten Rechen- 
systems wahrend des Aktualisierungsprozesses zu vermei- 
den. 

Weitere Moglichkeiten bestehen darin, daB die neue Soft- 
ware in dem Remote-Prozessor 40 mit Daten von dem 
Hauptprozessor 38 aktualisiert wird. Zudem konnen Funk- 
tionen zum Unterstutzen der Ubertragung von Daten von 
der alten zu der neuen Software bei dem Remote-Prozessor 
eingefuhrt werden. 

Nach der Beschreibung der Aktualisierung von Software 
in unterschiedlichen Systemkonfigurationen unter Einsatz 
des erfindungsgemaBen Zustandskopierverfahrens wird nun 
ein kombiniertes Aktualisieren von Hardware und Software 
unter Bezug auf die Fig. 10 bis 12 beschrieben. 

Die Fig. 10 bctrifft die Aktualisierung von Hardware des 
Hauptprozessors 38. Typischerweise werden Hardwarekom- 
ponenten ausgetauscht, indem die auszuwechselnden Hard- 
warekomponenten ausgekoppelt werden, anschlieBend 
diese ersetzt werden und schlieBlich ein erneutes Einkop- 
peln derselben durchgefuhrt wird. 

Die Fig. 11 zeigt den nachsten Fall, bei dem Software so- 
wohl in dem Remote-Prozessor 40 als auch dem Hauptpro- 
zessor 38 ohne EinfluB auf die Kompatibilitat der Schnitt- 
stelle aktualisiert wird. Ferner wird in dem in Fig. 11 gezeig- 
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ten Fall auch dem Remote-Prozessor 40 zugeordnete Hard- 
ware ausgewechselt. Hierfur werden auszutauschende Kom- 
ponenten, die dem Remote-Prozessor 40 zugeordnet sind, 
zunachst unter Einsatz unter Bezug auf die in Fig. 10 be- 
schriebene Vorgehensweise ausgewechselt. AnschlieBend 5 
wird die Software in dem Remote-Prozessor 40 und dem 
Hauptprozcssor 38 unter Einsatz dcr mit Bczug auf die Fig. 
8 beschriebene Vorgehensweise aktualisiert. 

Fig. 12 zeigt einen weiteren Fall fiir die Anwendung des 
Zustandskopierverfahrens, bei dem dem Remote-Prozessor 10 
zugeordnete Hardwarekomponenten gleichzeitig mit der 
Aktualisierung der Software des Remote-Prozessors und des 
Haupt-Prozessors 38 ausgewechselt werden, derart, daB eine 
Inkompatibilitat der Software nach der Aktualisierung ent- 
steht. Fuhrt die Veranderung der Hardware und Software im 15 
Hinblick auf den Remote-Prozessor 40 zu einer Inkompati- 
bilitat innerhalb des Remote-Prozessors und im Hinblick auf 
die neuen Hardware- und Softwarekomponenten, so wird 
zunachst die Hardware bei dem Remote-Prozessor 40 aus- 
gewechselt. AnschlieBend wird die Aktualisierung der Soft- 20 
ware, wie oben unter Bezug auf die Fig. 9 beschrieben, 
durchgefiihrt. 

Im Gegensatz hierzu ist die Situation komplizierter, wenn 
auch das Auswechseln der Hardwarekomponenten bei dem 
Remote-Prozessor 40 zu einer Inkompatibilitat im Hinblick 25 
auf die aktualisierte Software bei dem Remote-Prozessor 
flihrt. Ist die Veranderung der Hardware und der Software 
im Hinblick auf den Leistungsumfang des verteilten Re- 
chensystems unkritisch, so kann dieselbe Vorgehensweise 
eingesetzt werden, wie sie unter Bezug auf die Fig. 11 be- 30 
schrieben wurde. 

Ist diese Hardwareveranderung jedoch kritisch, so sollten 
die jeweiligen Hardwarekomponenten dupliziert bei dem 
Remote-Prozessor 40 vorgesehen sein, und auch die Soft- 
ware sollte entweder gemaB der Fig. 7 und 8 bei dem Re- 35 
mote-Prozessor 40 vorab geladen sein, oder der Remote- 
Prozessor 40 sollte zwei Parti tionen aufweisen. Eine weitere 
Anforderung fiir diesen Fall besteht darin, daB die Bearbei- 
tungsgeschwindigkeit des Remote-Prozessors 40 hoch ge- 
nug ist. Sind diese Bedingungen erfullt, so ist es moglich, 40 
die kornbinierte Aktualisierung ohne ubermaBige System- 
unterbrechung durchzufiihren. 
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Patentanspriiche 

1. Software-Bearbeitungsgerat vom Typ mit Aktuali- 
sierung s-Funktionalitat, enthaltend: 

a) eine Speichervorrichtung (6, 16), unterteilt in 
al) eine ausfiihrende Speicherpartitionie- 
rungsvorrichtung (6) zum Speichern einer er- 
sten Gruppe von Softwaremodulen und zu- 
geordneter Daten, und 

a2) eine Standby-Speicherpartitioniervor- 
richtung (16) zum Speichern einer zweiten 
Gruppe von Softwaremodulen und zugeord- 
neter Daten, 

b) eine Aktualisierungs-Steuervorrichtung (24) 
zum Aktualisieren eines Zustands der neuen Soft- 
ware in der Standby-Speicherpartitioniervorrich- 
tung (16) gemaB dem Zustand der alien Software 
in der ausfiihrenden Speicherpartitioniervorrich- 
tung (6) wahrend der Fortfiihrung der Durchfiih- 
rung der alten Software, und 

c) eine Ubertragungsvorrichtung (26) fur die ska- 
lierbare Ubertragung von Daten von der ausfiih- 
renden Speicherpartitioniervorrichtung (6) zu der 
Standby-Speicherpartitionier\ r orrichtung (16). 

2. Software-Bearbeitungsgerat nach Anspruch 1, da- 
durch gekennzeichnet, daB die Aktualisierungs-Steuer- 
vorrichtung (24) enthalt: 

d) eine Speicherverwaltungsvorrichtung (34) 
zum Allokieren und Deallokieren von Speicher- 
abschnitten fiir neue und alte Software und die 
Daten so wie zum Verw alten von Referenzinfor- 
mation hierfur, und 

e) eine Ubertragungssteuereinheit (30) zum Steu- 
ern der Ubertragungsvorrichtung (26) gemaB den 
Befehlen fiir die skalierbare Ubertragung von Da- 
ten. 

3. Software-Bearbeitungsgerat nach Anspruch 1 oder 
2, dadurch gekennzeichnet, daB die Aktualisierungs- 
Steuervorrichtung (24) ferner eine Umschaltvorrich- 
tung (32) enthalt, sowie eine Zu stands- Vergleichsvor- 
richtung (28) fiir das unmittelbare Umschalten zu der 
Durchfiihrung der neuen Software, sobald derselbe Zu- 
stand fiir die Standby-Speicherpartitioniervorrichtung 
(16) und die ausfiihrende Speicherpartitioniervorrich- 
tung (6) durch die Zustands- Vergleichsvorrichtung 
(28) detektiert ist. 

4. Software-Bearbeitungsgerat nach einem der An- 
spriiche 1 bis 3, dadurch gekennzeichnet, daB jeder 
Speicherpartitoniervorrichtung (6, 16) zumindest eine 
Ubernahmevorrichtung (8, 18) zugeordnet ist, und 
zwar zum Ausfiihren von Vorgabeaktionen fiir den 
Fall, daB Daten im Zusammenhang mit der alten Soft- 
ware lediglich zum Teil iibertragen wird, derart, daB die 
Ubernahmevorrichtung (8, 18) unmittclbar nach dem 
Umschalten aktiviert ist. 

5. Software-Bearbeitungsgerat nach einem der An- 
spriiche 1 bis 4, dadurch gekennzeichnet, daB die Uber- 
tragungsvorrichtung (16) entweder Daten unverandert 
kopiert oder nach einer Umsetzung in eine neue Dar- 
stellung fiir die neue Software iibertragt. 

6. Software-Bearbeitungsgerat nach Anspruch 5, da- 
durch gekennzeichnet, daB die Ubertragungsvorrich- 
tung (26) die Umsetzung von Daten parallel zu und 
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ohne Storung der Durchfiihrung der alten Software in 
der ausfuhrenden Speicherpartitioniervorrichtung (6) 
durchfuhrt. 

7. Software-Bearbeitungsgerat nach Anspruch 5 oder 

6, dadurch gekennzeichnet, daB die Ubertragungsvor- 5 
richtung (26) eine ausgewiesene Umsetzvorrichtung 
cnthalt. 

8. Software-Bearbeitungsgerat nach einem der An- 
spriiche 1 bis 7, dadurch gekennzeichnet, daB die Ak- 
tualisierungs-Steuervorrichtung (24) wiederholt den 10 
AktualisierungsprozeB solange durchfuhrt, bis die Um- 
schaltvorrichtung (32) zu der Durchfiihrung der neuen 
Software umschaltet, und zwar zum Verfolgen des sich 
verandernden Zustands in der ausfuhrenden Speicherp- 
artitioniervorrichtung (6). 15 

9. Software-Bearbeitungsgerat nach einem der An- 
spriiche 1 bis 8, dadurch gekennzeichnet, daB bei Vor- 
liegen von Daten im Zusammenhang mit der alten 
Software, die zum Zeitpunkt des Umschaltens nicht 
iibertragen sind, die Ubertragungsvorrichtung (26), 20 
falls erforderlich, diese Daten vor dem Start der neuen 
Software iibertragt. 

10. Software-Bearbeitungsgerat nach einem der An- 
spriiche 1 bis 9, dadurch gekennzeichnet, daB die Ak- 
tualisierungs-Steuervorrichtung (24) die Fortfiihrung 25 
der alten Software in der ausfuhrenden Speicherparti- 
tioniervorrichtung in dem Fall anweist, in dem eine 
Fehlersituation vor dem Umschalten auftritt. 

11. Software-Bearbeitungsgerat nach einem der An- 
spriiche 1 bis 10, dadurch gekennzeichnet, daB die Um- 30 
schaltvorrichtung (32) einen Riickschaltvorgang so 
durchfuhrt, daB die Partitionierung mit der alten Soft- 
ware erneut die ausfuhrende Speicherpartitioniervor- 
richtung (6) wird, und zwar in dem Fall, in dem ein 
Fehler wahrend der Durchfiihrung der neuen Software 35 
nach dem Umschalten auftritt. 

12. Verteiltes Rechensystem vom Typ mit Aktualisie- 
rungs-Funktionalitat, enthaltend: 

a) zumindest eine Hauptprozessorvorrichtung 
(38), ausgewahlt aus mehreren Prozessoren des 40 
verteilten Rechensy stems zum Handhaben der 
Verteilung der ProzeBteilaufgaben in dem verteil- 
ten Rechensystem sowie der Interaktionen der in 
diesem enthaltenden Prozessoreinheiten, 

b) zumindest eine Remote-Prozessorvorrichtung 45 
(40) mit einer Aktualisierungsvorrichtung (44) 
zum Aktualisieren neuer Software in einer Spei- 
cherpartition (46) der Remote-Prozessorvorrich- 
tung (40) derart, daB ein Zustand der neuen Soft- 
ware an einen Zustand der Hauptprozessorvor- 50 
richtung (38) angeglichen ist und die Durchfiih- 
rung der Software in der Remote-Prozessorvor- 
richtung zu der neuen Software umgeschaltet ist, 
sob aid der Abgleich erzielt ist. 

13. Verteiltes Rechensystem nach Anspruch 12, da- 55 
durch gekennzeichnet, daB fur den Fall einer nach der 
Aktualisierung der neuen Software in der Remote-Pro- 
zessorvorrichtung (40) immer noch kompatiblen 
Schnittstcllc zwischcn der Rcmotc-Prozcssorvorrich- 
tung (40) und der Hauptprozessorvorrichtung (48) die 60 
Hauptprozessorvorrichtung (38) gemaB einem der An- 
spriiche 1 bis 1 1 implementiert ist, zum Erzielen einer 
kombinierten Aktualisierung von Software in der Re- 
mote-Prozessorvorrichtung (38) und der Hauptprozes- 
sorvorrichtung (40). 65 

14. Verteiltes Rechensystem nach Anspruch 12, da- 
durch gekennzeichnet, daB im Fall einer nach der Soft- 
wareaktualisierung in der Hauptprozessorvorrichtung 



(38) und der Remote-Prozessorvorrichtung (40) nicht 
mehr kompatiblen Schnittstelle zwischen der Remote- 
Prozessorvorrichtung (40) und der Hauptprozessorvor- 
richtung (38) die Remote-Prozessorvorrichtung (40) 
nach einem der Anspriiche 1 bis 11 implementiert ist 
und gleichzeitig die Softwareaktualisierung zum An- 
glcichcn an die modifizicrtc Schnittstcllc durchfiihrt. 

15. Zustandskopierverfahren fiir ein Rechensystem 
mit zumindest zwei logischen Partitionen, enthaltend 
die Schritte: 

a) Aktualisieren eines Zustands der neuen Soft- 
ware in einer Standby-Partitioniervorrichtung 
(16) an den Zustand der alten Software in einer 
ausfuhrenden Partitioniervorrichtung bei Fortfiih- 
rung der Durchfiihrung der alten Software, 

b) Umschalten zum Durchfiihren der neuen Soft- 
ware, sobald derselbe Zustand fiir die Standby- 
Partitionierv r orrichtung (16) und die ausfuhrende 
Partitioniervorrichtung (6) erzielt wird. 

16. Zustandskopierverfahren nach Anspruch 15, da- 
durch gekennzeichnet, daB der Aktualisierschritt a) un- 
terteilt ist gemaB: 

c) Laden der neuen Software in die Standby-Par- 
titioniervorrichtung (16), und 

d) skalierbares Ubertragen von Daten von der 
ausfuhrenden Partitioniervorrichtung (6) zu der 
Standby-Partitioniervorrichtung (16). 

17. Zustandskopierverfahren nach Anspruch 15 oder 
1 6, dadurch gekennzeichnet, daB die Ubertragung von 
Daten von der ausfuhrenden Partitioniervorrichtung (6) 
zu der Standby-Partitioniervorrichtung (16) unterteilt 
ist gemaB: 

e) unverandertes Kopieren von zu iibertragenden 
Daten, und 

f) Umsetzen von umzusetzenden Daten in eine 
neue Darstellung fiir die neue Software. 

18. Zustandskopierverfahren nach Anspruch 17, da- 
durch gekennzeichnet, daB die Umsetzung von Daten 
parallel zu und ohne Storung der Durchfiihrung der al- 
ten Software in der ausfiihrenden Partitioniervorrich- 
tung (6) durchgefiihrt wird. 

19. Zustandskopierverfahren nach Anspruch 17 oder 
18, dadurch gekennzeichnet, daB die Umsetzung von 
Daten durch einen ausgewiesenen Umsetzschritt 
durchgefiihrt wird. 

20. Zustandskopierverfahren nach einem der Ansprii- 
che 15 bis 19, dadurch gekennzeichnet, daB der Aktua- 
lisierungsschritt a) auch einen Initialisierungsteilschritt 
aufweist, der parallel zu und ohne Storung der in der 
ausfuhrenden Partitioniervorrichtung (6) ablaufenden 
alten Software durchgefiihrt wird. 

21. Zustandskopierverfahren nach Anspruch 20, da- 
durch gekennzeichnet, daB der Initialisierungsschritt 
entweder unrnittelbar nach dem Laden der neuen Soft- 
ware in die Standby-Partitioniervorrichtung (16) 
durchgefiihrt wird oder sobald wie moglich, falls er 
Daten der alten Software erfordert. 

22. Zustandskopierverfahren nach einem der Ansprii- 
che 15 bis 21, dadurch gekennzeichnet, daB der Aktua- 
lisierungsschritt a) wiederholt als HintergrundprozeB 
solange durchgefiihrt wird, bis das Umschalten zu der 
neuen Software erfolgt, und zwar zum Verfolgen des 
sich verandernden Zustands in der ausfuhrenden Parti- 
tioniervorrichtung (6). 

23. Zustandskopierverfahren nach Anspruch 20 oder 
21, dadurch gekennzeichnet, daB der Aktualisierungs- 
schritt a) wiederholt parallel zu dem Initialisierungs- 
schritt durchgefiihrt wird. 
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24. Zustandskopierverfahren nach einem der Ansprii- 
che 15 bis 23, dadurch gekennzeichnet, daB fur den Fall 
von irn Zeitpunkt des Umschaltens nicht iibertragener 
Daten im Zusammenhang mit der alten Software diese 
Daten, falls erforderlich, vor dem Start der neuen Soft- 5 
ware iibertragen werden. 

25. Zustandskopierverfahren nach einem der Ansprii- 
che 16 bis 24, dadurch gekennzeichnet, daB im Teil- 
schritt d) Daten im Zusammenhang mit der alten Soft- 
ware lediglich teilweise ubertragen werden und daB ein 10 
spezieller Ubernahmeschritt unmittelbar nach dem 
Umschalten zum Durchfiihren von Vorgabeaktionen 
ohne vollstandige Eingabe von Daten durchgefuhrt 
wird. 

26. Zustandskopierverfahren nach einem der Ansprti- 15 
che 15 bis 25, dadurch gekennzeichnet, daB im Fall ei- 
nes Fehlers vor dem Umschalten die Aktualisierung 
abgeschlossen wird und die Durchfiihrung der alten 
Software in der ausfiihrenden Parti tioniervorrichtung 
(6) fortgefuhrt wird. 20 

27. Zustandskopierverfahren nach einem der Ansprii- 
che 15 bis 26, dadurch gekennzeichnet, daB ein Rlick- 
Umschaltschritt so durchgefuhrt wird, daB die ausfiih- 
rende Partitioniervorrichtung (6) mit der alten Software 
erneut die tatsachlich ausfiihrende Partitioniervorrich- 25 
tung (6) wird, und zwar im Fall eines Fehlers wahrend 
der Durchfiihrung der neuen Software nach dem Um- 
schalten. 

28. Zustandskopierverfahren nach Anspruch 27, da- 
durch gekennzeichnet, daB beim Ruck-Umschalten ei- 30 
nes Datenubertragung mit Datenkopieren und Umset- 
zen, falls erforderlich, durchgefuhrt wird, und zwar mit 
begrenzter oder ohne jegliche Stoning. 

29. Zustandskopierverfahren nach Anspruch 27 oder 
28, dadurch gekennzeichnet, daB beim Riick-Umschal- 35 
ten ein Wiederhers tells chritt durchgefuhrt wird, der vor 
dem erneuten Start der alten Software durchgefuhrt 
wird. 

30. Zustandskopierverfahren fur ein verteiltes Re- 
chensystern mit einer Hauptprozessorvorrichtung (38) 40 
und zumindest einer Remote-Prozessorvorrichtung 
(40), enth attend die Schritte: 

a) Aktualisieren der neuen Software in einer er- 
sten Speicherpartitioniervorrichtung (46) der Re- 
mote-Prozessorvorrichtung (40), 45 

b) Aktualisieren eines Zustands der neuen Soft- 
ware zum Erzielen eines Abgleichs mit dem Zu- 
stand der Haupt-Prozessorvorrichtung (38) bei 
Fortfuhrung der Durchfiihrung der Software in der 
Hauptprozessorvorrichtung (38), und 50 

c) Umschalten der Durchfiihrung der Software in 
der Remote-Prozessorvorrichtung (40) zu der 
neuen Software, sob aid ein Abgleich mit dem Zu- 
stand der Haupt-Prozessorvorrichtung (38) erzielt 
ist. 55 

31. Zustandskopierverfahren nach Anspruch 30, da- 
durch gekennzeichnet, daB bei nach der Aktualisierung 
der neuen Software in der Remote-Prozessorvorrich- 
tung (40) kompatibel blcibcndcn Schnittstcllc zwi- 
schen der Remote-Prozessorvorrichtung (40) und der 60 
Hauptprozessorvorrichtung (38) eine kombinierte Ak- 
tualisierung von Software in der Remote-Prozessorvor- 
richtung (40) und der Hauptprozessorvorrichtung (38) 
durchgefuhrt wird, durch zusatzliches Ausfuhren des 
Zustandskopierverfahrens nach einem der Anspriiche 65 
15 bis 29 in der Hauptprozessorvorrichtung (38). 

32. Zustandskopierverfahren nach Anspruch 30, da- 
durch gekennzeichnet, daB ein gleichzeitiges Aktuali- 
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sieren von Software in der Remote- Prozessorvorrich- 
tung (40) und der Hauptprozessorvorrichtung (38) mit 
modifizierter Schnittstelle durch gleichzeitiges Durch- 
fiihren des Zustandskopierverfahrens nach einem der 
Anspriiche 15 bis 29 in der Hauptprozessorvorrichtung 
(38) und der Remote-Prozessorvorrichtung (40) durch- 
gefuhrt wird. 

33. Zustandskopierverfahren nach einem der Ansprii- 
che 30 bis 32, dadurch gekennzeichnet, daB ferner an 
die Remote-Prozessorvorrichtung (40) angeschlossene 
Hardware-Komponenten ausgetauscht werden, und 
zwar durch Blockieren der auszutauschenden Hardwa- 
rekomponenten, anschlieBendes Ersetzen derselben 
und schlieBlich Freischalten derselben. 
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